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DESCRIPTION 

System and method for authenticating clients in a 

client- server environment 

Field of the present invention 

The present invention relates to authentication in general, and 
in particular to authentication in a client-server environment, 
and more specifically to authentication of clients in the 
Internet . 

Background of the invention 

Authentication is a procedure of determining whether someone or 
something is, in fact, who or what it is declared to be. In 
private and public computer networks authentication is commonly 
done by the use of logon passwords. Typically, every server 
maintains its own data persistency in order to store 
authentication data. Therefore, passwords which are available to 
the client on one server, may be already blocked by another 
client on another server. This increases the number of different 
authentication sets which have to be remembered and maintained 
by the client. In applications that are distributed over several 
servers with different user authentication systems (e.g. 
accessing an application through a portal server where the 
portal server uses its own user database) the client would have 
to logon more than once. 

Workarounds to allow single signon contain approaches like 
storing logon data for the application servers on the portal 
server or the use of Centralized user databases like 
Microsoft's® .NET Passport (http://www.passport.com) or Liberty 
from the Liberty Alliance (http://www.projectliberty.org) . This 
requires that the client is willing to have personal data stored 
on a third party site with all the data security issues that 
come along with this approach. Also if the Passport service 
should be down one cannot logon to the desired service even if 
the site one wants to use is available. 
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Using a user ID/password set for authentication also has the 
disadvantage that it results in extra network traffic. On a 
client request the server has to answer by asking for the login 
data. Only after this is provided, the originally requested 
information is sent back to the client (see also Pig. 7A below) . 

Finally, passwords can often be stolen, accidentally revealed, 
or simply forgotten. 

For this reason, Internet business and many other transactions 
require a more stringent authentication process. The use of 
digital certificates issued and verified by a Certificate 
Authority (CA) as part of a public key infrastructure is 
considered to become the standard way to perform authentication 
on the Internet. 

Digital signatures enable the recipient (server) to verify the 
identity of the sender (client) and the origin as well as the 
integrity of the document. 

Digital signatures are based on asymmetric cryptographic 
algorithms. The documents are signed with the private key of the 
sender. The recipient can take the sender's public key, which is 
provided to him by a Trusted Third Party, and validate the 
integrity of the document received. 

The implementation of a digital signature procedure into an 
already existing password logon infrastructure requires great 
modifications on the server side as well as the client side, 
e.g. additional card reader with specific security applications. 
Therefore, such implementations cause much effort on costs and 
time with the consequences that preferably only new client - 
server infrastructures will be using the digital signature 
procedure. The existence of those two authentication procedures 
in the client- server environment has the disadvantage that a 
client has to check at first whether the destination server is. 
supporting the password logon or the digital signature 
procedure. Depending on that result the client will use the 
-j^quixad^_authentica tion process sup ported by the server. It 
causes much unnecessary network traffic between client and 
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server, since the server application -it-o^i* -, -, ^ 

* ct^pxicacion itself finally determines 

the type of authentication. 

Furthermore, the present digital signature authentication 
procedures have the disadvantage that several screens between 

untr t r d i ^ t0 bS eXChan ^ ed ^ween client and server 

until the client can provide its authentication information. 
Tins causes much unnecessary network traffic. 



Object of the invention 



Starting from this, the object of the present invention is to 
provide a method and system for authenticating clients in a 
client-server environment by avoiding the disadvantages of the 
above-mentioned prior art. 



Brief summary of the invention 



The idea of the present invention is to replace the existing 
password/user ID based authentication process by a new digital 

™? reol a tTT Ca tl0n Pr ° 0eSB in ™ hiCh th. first . 

HTTP-request header is extended by the client authentication 

thf°Z^° n . Penden " y ° f authenti ^ion process used by 

the destination server and without server requesting 

authentication information. The authentication information 

121ZT Y lnClUd r CliSnt Ce " ificate -ntaining the client 
Public key. signed by certification authority, and preferably a 
hash value calculated over the HTTP-request header data being 
sent in the request, and encrypted with the Client's private 
key. The certificate and digital signature may be added during 
the creation of the HTTP-request header in the client system 
itself, or may be added later in a server acting as a gateway, 
proxy, or tunnel. * 

A destination server that does not support the new digital 
signature authentication process will simply ignore the 
certificate and digital signature in the HTTP-request header and 
will automatically initiate its own authentication process. The 

* 1 
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present invention simplifies the existing digital signature 
authentication process and concurrently allows the coexistence 
of different authentication processes without changing the HTTP- 
protocol or causing unnecessary network traffic. 

Brief Description of the several views of the drawings 

The above, as well as additional objectives, features and 
advantages of the present invention will be apparent in the 
following detailed written description. 

The novel features of the invention are set forth in the 
appended claims. The invention itself, however, as well as a 
preferred mode of use, further objectives, and advantages 
thereof, will be best understood by reference to the following 
detailed description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 

Fig.l A/B show prior art HTTP -client -server environments in 
which the present invention is preferably used, 

Fig. 2 shows the basic structure of a typical prior art HTTP- 
header , 

Fig. 3 shows the inventive structure of the HTTP-header with the 
certificate and the digital signature, 

Fig. 4 A-D show preferred embodiments to insert the certificate 
together with the digital signature into the HTTP -request header 
resulting in the inventive structure of the HTTP-request header, 

Fig. 5 shows an example of a server-client communication 
environment using the present invention, 

Fig. 6 shows a preferred embodiment of the authentication data 
flow in an client- server environment according to Fig.l A using 
the inventive atruc^ureT^ 
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process with the inventive authentication process of the present 
invention based on an examnl present 
process . example of a online purchase transaction 



cllL A «d ws.x Bl there are depiote<J 

client-server environments in which the present invention is 
preferably used. However it should be noted that the present 
invention may be used on each client-server environment ITL 
communication protocols allowing header extensions without 
violating normal protocol usage. Therefore, the present 

ZZZ Tl ±tB Preferre<1 »*» - ascribed and 

explained on the currently mostly known HTTP-protocol . 

ZllTl' Pr °T 01 <HyPertext ^" r ansf er Protocol, is an 
application level protocol for distributed systems. It is a set 

video 1 , eXChanSl » 9 graphic, images, sound" 

video and other multimedia files, . Any web server machine 3 ' 
contain a HTTP-daemon or so called HTTP- server 4. a program ' 

ZIT Ttr a " Walt *" — -ndle^nTwhen 

arrive. Furthermore, each client machine 1 contains a web 

browser or so-called HTTP-cli»„.- ■> „__.>• 

server- , client 2, sending requests to web 

server machine 3. When the browser user sn f «r. . 

WBCX user enters a reouest lw 

either opening a web file (typing in a URL) or oi ■ by 
^ertext link, the browser b^ilL L H^L^e tTs^ it 
to the internet Protocol Address indicated in the rax, ^http 

reoTV ^ deStlnation — 3 receives the 

request and. after processing, the requested file is returned 
in another client-server environment client 1 is communing 

(see ITsTT 3 3 9atSWay ' . 3 ~ « * P-y-erver f 

Usually HTTP takes place over TCP/IP (Trar^nH oc • 

ProMnnl /T . (Transmission Control 

Protocol/internet Protocol, . however HTTP is not dependent on 

Internet"" ■ \ ^ °* ^ "* 6X01131196 with «her 

a set of ^ in ™ ion ^-el, and ip defines 
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An HTTP-request header consists of the HTTP method (GET, HEAD, 
POST, etc.), the Universal Resource Identifier (URI) , the 
protocol version and optional supplemental information. 

An HTTP-response consists of a status line, which indicates 
success or failure of the request, a description of the 
information in the response (meta information) and the actual 
information request. 

With respect to Fig. 2, there is depicted the basis structure of 
a prior art HTTP-request header. Each HTTP-request must contain 
at least a header. Only HTTP-Post requests contain header and 
body data. Following information are preferably contained in a 
HTTP-request header: 

Resources to be accessed by the HTTP-request (e.g. file, 
servlet) 

The host name of the server (e.g. www.ibm.com) 

Browser name and version (e.g. Netscape Version 7.1) 

Operating system of the client (e.g. Windows XP) 

Character set that can be understood by the browser (e.g. iso- 

8859-1) . 

Each HTTP-header may include supplemental information not 
defined by the HTTP -protocol and which does not conflict with 
existing applications using the HTTP - pro t oco 1 . That means that 
an application which uses the HTTP-protocol and which is not 
configured to process that supplemental information simply 
ignores that supplemental information without interrupting its 
execution. 

With respect to Pig. 3, there is depicted the inventive structure 
of a HTTP-request header according to the present invention. 
Following additional information according to the present 
invention must be included into the HTTP-request header: 
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°" ent .° ertifiCate contai ^9 the public key and signed by a 
certifxcatxon authority, and 

digital signature calculated over the HTTP-request header and if 
available HTTP-body (Post) . 

The certificate and digital signature can be processed by 
specxfic tools on the server. A client certificate is a document 
dxstrxbuted by a Trusted Third Party that binds a public key to 
a specxfic person. The Trusted Party guarantees that the 
information contained in the certificate is valid and correct 
Certxfxcates are standardized by 509. They should contain the 
dxgxtal signature of the Trusted Third party, the name of the 
person owning the public key, and the public key itself 
With respect to Fig. 4 A-C, there are depicted preferred 
embodiments to insert the client certificate and the digital 
signature into the HTTP-request header. 

With respect to Pig. 4 A, there is depicted a first embodiment 
of the present invention to insert Client's certificate 16 
together with the digital signature 18 into the HTTP-request 
header 12. The client system 1 contains a browser 2 with 
signature capabilities. The browser 2 generates a HTTP-request 
header 12, accesses the client's private key which is securely 
stored on a local file system, encrypts a hash value generated- 
over the HTTP-request header 12 and if available body, with the 
prxvate key resulting in a digital signature 18. That digital 
sxgnature 18 together with the Client certificate 16 containing 
the public key is inserted in the HTTP-request header 12 The 
extended HTTP-request header 14 is sent to the HTTP-server 4 
that initiates the authentication process. The authentication 
component 6 which may be part of the HTTP-server or may be a 
separate component verifies the client certificate information 
16 from the HTTP-request header. Verification can either be done 
by checking the certificate signature of Certification Authority 
or comparing it with already known certificates contained in its 
certxfxcation database 9. Using the public key contained in the 
clxent certificate 16, the digital signature 18 contained in the 
HTT-request header 12 is decrypted resulting in a hash value 
calculated by the client 1. Using the same hash algorithm, the 
hash value is calculated over the HTTP-request header 12 and 
body if available. If hash values match verification is 
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completed and the authentication is successful and access to an 
application 8 is given. 

With respect to Pig. 4 B, there is depicted a second embodiment 
of the present invention to insert Client certificate 18 
together with the digital signature 16 into the HTTP-request 
header 12 . Now the browser 2 has the functionality to 
communicate with a smart card 10 via a smart card reader 10. The 
browser 2 generates a HTTP -request header, establishes 
communication with the smart card 10, the smart card 10 which 
contains in its security module a private key and Client's 
certificate encrypts a hash value generated over the HTTP-header 
12 and if available body, with the private key (digital 
signature) , and returns a digital signature 18 together with 
client's certificate 16 to the browser 2. That digital signature 
18 together with Client's certificate 16 containing the public 
key is inserted in the HTTP-request header 12 . The extended 
HTTP-request header 14 is sent to the HTTP- server 4 that 
initiates the authentication process by using an authentication 
component (see description to Fig. 4 A) 

With respect to Fig. 4 C, there is depicted a third embodiment of 
the present invention to insert Client's certificate 16 together 
with the digital signature 18 into the HTTP-request header 12. 
In the third embodiment the client system contains an own 
signature component 20. That component acts as a proxy server 
running on the same client 1 as the browser 2 . The browser 2 is 
configured to use that proxy server 20. Because of this the 
browser 2 sends the regularly HTTP -request header 12 to the 
signature component 20 which then inserts the certificate 16 and 
digital signature 18 analog to the embodiments as described 
above. The extended HTTP-request header is sent to the HTTP- 
server 4 that initiates the authentication process by using an 
authentication component (see description to Fig. 4 A) . 
With respect to Fig. 4 D, there is depicted a fourth embodiment 
of the present invention to insert Client certificate 18 
together with the digital signature 16 into the HTTP-request 
header 12 . — In that em bod"±n ienL th ernrlxent — reques t ( 1 a-/-£a-; — lb/^b> 
is routed via a proxy server 22 having an insertion component 
20. The insertion component 20 is communicating with an 
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encryption hardware 24 containing private keys and their 
assigned certificates, which encrypts a hash value generated 
over the HTTP-request header 12 and if available body, with the 
private key (digital signature) , and returns digital signature 
18 with the client certificate 16 to the insertion component 20 
inserting them into the HTTP-request header 12 . The extended 
HTTP-request header 14 is sent to the HTTP-server 4 that 
initiates the authentication process by using an authentication 
component (see description to Fig. 4 A) . 

Anyway, because the present invention describes additional 

header data in the HTTP protocol, all combinations of existing 

clients and servers that are able to process the additional data 

xn the header can work together. If one of the systems is not 

enabled to handle additional data everything will work as known 
today . 

* 

To keep the existing base of billions of installed client 
browsers, an additional signature software could handle the HTTP 
extension by acting as a proxy component on the local client 
machine (see Pig. 4C) . Within company networks (e.g. intranet) 
this could even be handled by a central proxy server (Fig 4C ) : 
Future versions of Web Browsers then may have the functionality 
buxld in (Fig 4 A) . This way the transition to the new paradigm 
can happen over time. 

The digital signature can be created using a signature smart 
card or any other signature hardware. Also a pure software 
solution with an encrypted key store on the client computer 
would be a possible implementation. 

Pig. 5 shows an example of a server-client communication 
environment using the present invention. 

In this example it is assumed that an application 5 is accessed 
through a portal server 3 . In the state of art this situation is 
handled by either storing the client's identity data on a server 
that is accessible by the portal server 3 and the application 
server 5 (e.g. Microsoft's® .NET Passport) or the identity data 
for the application server needs to be stored on the portal 
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server 3 . Both approaches require the user to have his/her data 
stored on a third party system which is subject to many security 
issues . 

By digitally signing the request as explained in Fig .4 A-D, no 
server needs to store the user data. The portal server 3 can 
check the identity of the requester against its user database 4 , 
passing the request along to the application server 5 which can 
do the same using its user database 6 . Client 1 a accesses the 
application server 5 through the portal server 3 while Client 1 
b can access the application server 5 directly. The application 
server 5 can use its own user database 6 to retrieve profile 
information for the user. 

The approach even provides higher security since the application 
server 5 might want to handle only those requests that passed 
the portal server 3 . In this case the portal server 3 forwards 
the request and additionally signs it. This enables the 
application server 5 to verify both signatures in order to 
either grant or deny access to its services. Client la would 
gain access to the application server 5 while Client lb would 
not be served because its request does not go through the portal 
server 3 . 

With respect to Fig. 6, there is depicted the authentication a 
data flow according to the present invention. 
Client's browser prepares request to the server 10. In a 
preferred embodiment of the present invention it will be checked 
whether signing of the HTTP-request header is switched on 20. If 
not, Client's browser will send a non-signed request to the 
server 40 and the server checks whether signing is required 50. 
If signing is required server will send an error message to the 
client 50. If signing is not required the server will provide 
access to the desired information 60. 

If signing is switched on the client's browser inserts 
certificate and digital signature into the HTTP- request header, 
ana send^^Jmr - HTTP^equesL hBaiier^o*^he^s-e^v^-r--3-0^ 



DE9-2003-0011 

- 11 - 



By appending the extra fields to the HTTP header request header 
the server is able to retrieve the requester's identity from the 
certificate (authentication) 35. 

The Client's certificate contains the requester's name and 
public key. 

Because it is signed by a trusted authority, the server is able 
to verify that it is a valid certificate issued by the trusted 
authority. Verification that the message has been really sent 
by the owner of the certificate is possible, because only the 
owner of the private key belonging to the certificate can have 
generated the digital signature value in the HTTP-request header 
which has been calculated over the HTTP-request header data and 
can be verified through the use of the public key contained in 
the certificate. If the authentication has been successful, the 
server provides access to the requested data 60. 

With respect to Fig. 7 A, B , there are depicted typical scenarios 
of the exchange of information between Web browser (client) and 
Web server (server) using the prior art authentication process 
xn comparison with the inventive authentication process of the 
present invention. 



For example, during a purchase process, the client receives and 
sends data (e.g. a series of text or html pages or blocks of 
formatted data like XML) from and to the server representing the 
online shopping system until the order gets confirmed by a 
specific data transfer operation (e.g. HTTP Post). In today's 
applications, the server issues a request to obtain a user Id 
and password from the client during this process. The user has 
to supply these data manually before they are sent to the server 
by the client application (see Fig.7A) . 

In an application corresponding to the present invention (see 
Fi9-7 B), the client signs the HTTP-request header data being 
sent to the server by means of a digital signature. The server 
easily identifies the client by checking the signature. It's 
therefore not necessary to request and supply the user Id and 
password, since every data item transmitted is associated with 
the user's identity. The server may retrieve stored information 
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for this client and use this information in preparing the data 
which is to be sent to the client ("personalization", profile 
creation page) . Examples for data used for personalization are 
the user's address (where should the ordered items be delivered 
to) , the users shopping history, the users shopping cart, the 
web pages visited during the last sessions etc. 

By checking the identity of the user (which can be done at any 
time during the flow) , the server may find out that the user 
never visited this site before. The server may then send data 
containing a request to specify preferences and detailed user 
data (profile creation page) . The user supplies these data, the 
client application sends it to the server and the server stores 
these data used for personalization in its data base. 

Since every data transfer is signed, the user ID of the client 
is known to the server as soon as the client visits the first 
page. The personalization may therefore take place early during 
the process. 

When the user chooses to switch off signing, the server 
recognizes this fact and may send a page containing an 
indication to switch on signing or might use traditional user ID 
/ password scenarios instead (not shown) . 



13 
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CLAIMS 



1. Method for authenticating clients in a client-server 
environment, wherein said client-server environment uses a 
communication protocol that allows extensions of the header 
request without violating said communication protocol, wherein 
said client comprises the steps of: 

generating a header request (10), 

inserting client authentication information into said header 
request resulting in an extended header request (20) 
independently of the authentication process used by said server 
and without server requesting authentication information 

* 

sending said extended header request to a server (30) , 

and. receiving information from said server if authentication has 
been successful (35,60). 

2. Method according to claim 1, wherein said communication 
protocol is a HTTP - protocol . 

3. Method according to claim l, wherein said authentication 
information is included in the first header request for 
establishing a session with said server. 

4. Method according to claim l, wherein said authentication 
information comprises the client certificate containing client's 
name and client public key, and a digital signature which has 
been generated over a hash value of the header request including 
client certificate using Client private key. 

5. Method according to claim 1, wherein said authentication 
information is automatically inserted into said header request 
by the Client's browser. 



- 14 - 
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6. Method according to claim 5, wherein said client browser 
receives said authentication information from a smart card (10) 
via a smart card reader. 

7. Method according to claim 1, wherein said authentication 
information is automatically inserted into said header request 
by a client signature component (20) which receives said 
authentication information from a smart card (10) via a smart 
card reader. 

8. Method for authenticating clients (la, lb) in a client-server 
environment, wherein said client-server environment uses a 
communication protocol that allows extensions of the header 
request without violating said communication protocol, wherein a 
system (22) establishes communication between said client (la, 
lb) and said server (3), wherein said system(22) comprises the 
steps of: 

receiving a header request from said client (la, lb) , 

inserting authentication information into said header request 
resulting in an extended header request (20) independently of the 
authentication process used by said server and without server 
requesting authentication information, 

sending said extended header request to a server (3) , and 

receiving information from said server (3) , if the 
authentication has been successful. 

9. Method according to claim 8, wherein said system (20) can be 
a proxy server, a gateway, or a tunnel. 

10. Method according to claim 8, wherein said communication 
protocol is the HTTP - protocol , and said authentication 
information is automatically inserted into said HTTP-request 
header by said an insertion component (20) which receives said 
authentication ilTtormatxcSrr^fTam "a s iynatuxe~componen-t: — (-2-4-)— 
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11. Method according to claim 8, wherein said authentication 
information comprises the client certificate containing client's 
name and client's public key, and a digital signature which has 
been generated over the whole header request including client 
certificate using Client's private key. 

12. Method for authenticating clients in a client-server 
environment, wherein said client-server environment uses a 
communication protocol that allows extensions of the header 
request without violating said communication protocol, wherein 
at said server side said method comprises the steps of .- 



receiving a client header request containing authentication 
information, 

validating said authentication information contained in said 
header request by said server authentication component, and 

providing information to said client, if the authentication has 
been successful . 

13. Method according to claim 12, wherein said authentication 
information comprises the client certificate containing client's 
name and client's public key, and a digital signature which has 
been generated over the whole header request content using 
Client's private key. 

14. Method according to claim 12, wherein said communication 
protocol. is the HTTP-protocol, and said authentication component 
performs the steps of: 

accessing said public key contained in the client certificate 
decrypting said digital signature contained in the HTTP-request 
header with said public key resulting in a hash value, 
applying the same hash algorithm as used . by said client to said 
HTTP-request header, and 

considering authentication as successful, if both hash values 
match . 

15. Server System (3) for authenticating clients (1) in a 
client- service environment, wherein said client- server 
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environment uses a communication protocol that allows extensions 
of the header request without violating said communication 
protocol, wherein said client (1) provides authentication 
information in the header request to said server system, wherein 
said server system (3) comprising: 

an authentication component (4) with the functionality to read 
said authentication information contained in the incoming client 
header request, and to validate said authentication information 
without having requested said authentication information from 
said client . 

16. Client System (1) to be authenticated by a server system in 
client- server environment, wherein said client- server 
environment uses a communication protocol that allows extensions 
of the header request without violating said communication 
protocol, wherein said client system comprising: 

a browser (2) , and 

a component for inserting client authentication information into 
said header request independently of the authentication process 
used by said server and without server requesting authentication 
information . 

17. Client System according to claim 16, wherein said 
authentication information comprises the client certificate 
containing client's name and client's public key, and a digital 
signature which has been generated over the hash value of the 
header request content using Client's private key. 

18. Client System according to claim 16, further comprising 
a smart card reader (10) , and 

a smart card (10) with a security module containing client's 
private key and a client certificate containing client name and 
private key, wherein said smart card provides said certificate 
together with a digital signature to said inserting component, 
wherein said digital s lgnatTire^s^ 

a hash value of said header request containing said certificate 
information by means of said private key. 



DE9-2003-0011 



19 Proxy Server system (22, for providing client authentication 

ziir.iT: t° a server system <3> ' wherein — 

evetem 22) has a communication connection with a client system 
Ua lb) and a server system (3) , wherein said communication 
protocol used between said systems allows extensions of the 
header request of said header request without violating said 

communication protocol, wherein c»-iri rw~„ 

. . ' wner em said proxy server system (22) 

comprising: y 



a proxy insertion component (20) for inserting the client 
certificate and digital signature into the header request 
received from said client independently of the authentication 
process used by said server and without server requesting 
authentication information, and 

1 

■ i 

a signature component (24) for creating a digital signature and 
for providing it together with said client certificate to said 
proxy insertion component (20) . 

20^ computer program product stored in the internal memory of a 

thrmlVr^"' C ° ntaini "9 ***** <* software code to execute 
the method m accordance with claim 1-14 if the product is run 
on the computer. 



18 
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ABSTRACT 



The idea of the present invention is to replace the existing 
password/user ID based authentication process by a new digital 
Signature authentication process in which preferably the first 
HTTP-request header is extended by the client authentication 
information independently of the authentication process used by 
the destination server and without server requesting 
authentication information. The authentication information 
preferably includes the client certificate containing the client 
public key, signed by certification authority, and preferably a 
hash value calculated over the HTTP-request header data being 
sent in the request, and encrypted with the Client's private 
key. The certificate and digital signature may be added during 
the creation of the HTTP-request header in the client system 
itself, or may be added later in a server acting as a gateway, 
proxy, or tunnel. A destination server that does not support the 
new digital signature authentication process will simply ignore 
the certificate and digital signature in the HTTP-request header 
and will automatically initiate its own authentication process 
The present invention simplifies the existing digital signature 
authentication process and concurrently allows the coexistence 
of different authentication processes without changing the HTTP- 
protocol or causing unnecessary network traffic. 
(Figure 6) 
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POST /webapp HTTP/1.1 
Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us,en 
Accept-Encoding: gzip.deflate 
Accept-Charset: ISO-8859-1 ,utf-8 
Keep-Alive: 300 
Connection: keep-alive 
Content-Length: 21 

<any data to be sent> 
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POST /webapp HTTP/1 . 1 
Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us.en 
Accept-Encoding: gzip.deflate 
Accept-Charset: ISO-8859-1 ,utf-8 
Keep-Alive: 300 

Connection: keep-alive 
Content-Length: 21 

X-Certificate: Requestor certificate> 
X-Sfgnature: <digital signature> 

<any data to be sent> 
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Client 

Web Browser with 
Signature Capabilities 




.GET /HTTP/1.1 

Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us,en 
Accept-Encoding: gzip.deflate 
Accept-Charset: ISO-8859-1 ,utf-8 
Keep-Alive: 300 
Connection: keep-alive 
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GET /HTTP/1.1 
Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us,en 
i Accept-Encoding: gzip.deflate 
Accept-Charset: ISO-8859-1 ,utf-8 

Keep-Alive: 300 
Connection: keep-alive 
X-Certificate: <requestor certificate^ 
X-Signature: <digital signature 

X 
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GET /HTTP/1.1 
Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us,en 
Accept-Encoding: gzip.deflate 
Accept-Charset: ISO-8859-1,utf-8 
Keep-Alive: 300 
Connection: keep-alive 




GET /HTTP/1.1 
Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us,en 
Accept-Encoding: gzip.deflate 
Accept-Charset: ISO-8859-1 ,utf-8 
Keep-Alive: 300 
Connection: keep-alive 
X-Certificate: -^requestor certificate^ 
X-Signature: <dig'rtal signature> 
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GET /HTTP/1.1 
Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us,en 
Accept-Encoding: gzip.deflate 
Accept-Charset: ISO-8859-1 ,utf-8 
Keep-Alive: 300 
Connection: keep-alive 



GET /HTTP/1.1 
Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us,en 
Accept-Encoding: gzip,deflate 
Accept-Charset: ISO-8859-1 ,utf-8 
Keep-Alive: 300 
Connection: keep-alive 
X-Certificate: <requestor certificate> 
X-Signature: <digital signature> — 
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GET /HTTP/1.1 
Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us,en 
Accept-Encoding: gzip.deflate 
Accept-Charset: ISO-8859-1 ,utf-8 
Keep-Alive: 300 
Connection: keep-alive 
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GET /HTTP/1.1 
Host: www.server.xx 
User-Agent: Browser XYZ 
Accept-Language: en-us,en 
Accept-Encoding: gzip.deflate 
Accept-Charset: ISO-8859-1 ,utf-8 
Keep-Alive: 300 

Connection: keep-alive 
X-Certificate: requestor certificate> 
X-Signature: <digital signature> 
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